Frontend Web OTP காலக்கெடுவை நிர்வகித்தல்: எஸ்எம்எஸ் கட்டமைப்பிற்கான ஒரு உலகளாவிய வழிகாட்டி

டிஜிட்டல் உலகில், எஸ்எம்எஸ் வழியாக அனுப்பப்படும் எளிய ஒருமுறை கடவுச்சொல் (OTP) பயனர் சரிபார்ப்பின் மூலக்கல்லாக மாறியுள்ளது. உங்கள் வங்கியில் உள்நுழைவது முதல் உணவு விநியோகத்தை உறுதிப்படுத்துவது வரை அனைத்திற்கும் இதுவே டிஜிட்டல் வாயிற்காப்போன். இது வெளிப்படையாகத் தோன்றினாலும், ஒரு OTP ஓட்டத்தின் பயனர் அனுபவம் நம்பமுடியாத அளவிற்கு நுட்பமானது. இந்த அனுபவத்தின் மையத்தில் ஒரு சிறிய ஆனால் சக்திவாய்ந்த விவரம் உள்ளது: காலக்கெடு கட்டமைப்பு (timeout configuration). அதைச் சரியாகச் செய்தால், செயல்முறை தடையற்றதாக இருக்கும். அதைத் தவறாகச் செய்தால், நீங்கள் குறிப்பிடத்தக்க உராய்வு, விரக்தி மற்றும் பயனர்கள் வெளியேறும் அபாயத்தை உருவாக்குகிறீர்கள்.

இது வெறும் ஒரு நிறுத்தக்கடிகாரத்தைத் தொடங்குவது மட்டுமல்ல. இது வலுவான பாதுகாப்பு, உள்ளுணர்வு பயனர் அனுபவம் மற்றும் உலகளாவிய தொலைத்தொடர்பு நெட்வொர்க்குகளின் கணிக்க முடியாத உண்மைகளுக்கு இடையே ஒரு சிக்கலான சமநிலைப்படுத்தும் செயல். 5G கவரேஜ் உள்ள ஒரு பெருநகரப் பகுதியில் சரியாக வேலை செய்யும் ஒரு காலக்கெடு, விட்டுவிட்டு இணைப்புள்ள ஒரு கிராமப்புறப் பகுதியில் உள்ள வாடிக்கையாளருக்கு முற்றிலும் பயன்படுத்த முடியாததாக இருக்கலாம். ஒரு புதிய குறியீட்டைக் கோருவதற்கு முன் ஒரு பயனர் எவ்வளவு நேரம் காத்திருக்க வேண்டும்? ஒரு எஸ்எம்எஸ் வருவதற்கு நியாயமான எதிர்பார்ப்பு என்ன? நவீன உலாவி API-கள் இந்த விளையாட்டை எப்படி மாற்றுகின்றன?

இந்த விரிவான வழிகாட்டி frontend Web OTP காலக்கெடு கட்டமைப்பின் கலையையும் அறிவியலையும் பிரித்து ஆராயும். நாங்கள் கருத்தில் கொள்ள வேண்டிய முக்கிய காரணிகளை ஆராய்வோம், செயல்படுத்தலுக்கான சிறந்த நடைமுறைகளை ஆய்வு செய்வோம், நடைமுறை குறியீடு உதாரணங்களை வழங்குவோம், மேலும் பாதுகாப்பான, பயனர் நட்பு மற்றும் உலகளவில் நெகிழக்கூடிய ஒரு சரிபார்ப்பு ஓட்டத்தை உருவாக்குவதற்கான மேம்பட்ட உத்திகளைப் பற்றி விவாதிப்போம்.

OTP வாழ்க்கைச் சுழற்சி மற்றும் காலக்கெடுவின் பங்கை புரிந்துகொள்ளுதல்

நாம் காலக்கெடுவை உள்ளமைப்பதற்கு முன், ஒரு OTP எடுக்கும் பயணத்தை முதலில் புரிந்து கொள்ள வேண்டும். இது கிளையன்ட் (frontend) மற்றும் சர்வர் (backend) இரண்டையும் உள்ளடக்கிய ஒரு பல-படி செயல்முறையாகும். எந்த ஒரு கட்டத்திலும் ஏற்படும் தோல்வி அல்லது தாமதம் முழு ஓட்டத்தையும் சீர்குலைக்கும்.

1. கோரிக்கை: பயனர் ஒரு செயலைத் தொடங்குகிறார் (எ.கா., உள்நுழைவு, கடவுச்சொல் மீட்டமைப்பு) மற்றும் தனது தொலைபேசி எண்ணை உள்ளிடுகிறார். frontend ஒரு OTP-ஐ உருவாக்கி அனுப்ப backend API-க்கு ஒரு கோரிக்கையை அனுப்புகிறது.
2. உருவாக்கி சேமித்தல்: backend ஒரு தனித்துவமான, சீரற்ற குறியீட்டை உருவாக்குகிறது. இது இந்த குறியீட்டை, அதன் காலாவதி நேரம் மற்றும் தொடர்புடைய பயனர்/தொலைபேசி எண்ணுடன், ஒரு தரவுத்தளத்தில் (Redis அல்லது ஒரு நிலையான SQL அட்டவணை போன்றவை) சேமிக்கிறது.
3. அனுப்புதல்: backend ஒரு எஸ்எம்எஸ் கேட்வே சேவையுடன் (Twilio, Vonage, அல்லது ஒரு பிராந்திய வழங்குநர் போன்றவை) தொடர்பு கொண்டு OTP குறியீட்டை பயனரின் மொபைல் எண்ணுக்கு அனுப்புகிறது.
4. வழங்குதல்: எஸ்எம்எஸ் கேட்வே செய்தியை சர்வதேச மற்றும் உள்ளூர் மொபைல் கேரியர்களின் ஒரு சிக்கலான வலை வழியாக பயனரின் சாதனத்திற்கு அனுப்புகிறது. இது பெரும்பாலும் மிகவும் கணிக்க முடியாத படியாகும்.
5. பெற்று உள்ளிடுதல்: பயனர் எஸ்எம்எஸ்-ஐப் பெறுகிறார், குறியீட்டைப் படிக்கிறார், மற்றும் அதை உங்கள் இணையப் பயன்பாட்டில் உள்ள உள்ளீட்டு புலத்தில் கைமுறையாக உள்ளிடுகிறார்.
6. சரிபார்த்தல்: frontend பயனரால் உள்ளிடப்பட்ட குறியீட்டை சரிபார்ப்பதற்காக backend-க்கு மீண்டும் அனுப்புகிறது. backend சேமிக்கப்பட்ட குறியீட்டுடன் அது பொருந்துகிறதா என்றும், அது இன்னும் அதன் செல்லுபடியாகும் காலத்திற்குள் உள்ளதா என்றும் சரிபார்க்கிறது.

இந்த வாழ்க்கைச் சுழற்சிக்குள், பல தனித்துவமான 'காலக்கெடு' செயல்பாட்டில் உள்ளன:

• OTP செல்லுபடியாகும் காலம் (சர்வர்-பக்கம்): இது மிக முக்கியமான பாதுகாப்பு காலக்கெடுவாகும். இது OTP குறியீடு எவ்வளவு காலம் backend-ஆல் செல்லுபடியாகும் என்று வரையறுக்கிறது. பொதுவான மதிப்புகள் 2 முதல் 10 நிமிடங்கள் வரை இருக்கும். இந்த காலம் முடிந்தவுடன், பயனர் அதைச் சரியாக உள்ளிட்டாலும் குறியீடு செல்லாது. இது முற்றிலும் ஒரு backend சம்பந்தப்பட்ட விஷயம்.
• "மீண்டும் குறியீட்டை அனுப்பு" கூல்டவுன் (கிளையன்ட்-பக்கம்): இது frontend-இல் பயனருக்குத் தெரியும் டைமர் ஆகும். இது பயனர் முதல் கோரிக்கைக்குப் பிறகு உடனடியாக 'மீண்டும் அனுப்பு' பொத்தானை ஸ்பேம் செய்வதைத் தடுக்கிறது. அசல் எஸ்எம்எஸ் வருவதற்கு ஒரு நியாயமான வாய்ப்பைக் கொடுப்பதை இது நோக்கமாகக் கொண்டுள்ளது. இதுவே நமது விவாதத்தின் முதன்மை கவனம்.
• API கோரிக்கை காலக்கெடு (நெட்வொர்க்): இவை frontend மற்றும் backend-க்கு இடையேயான API அழைப்புகளுக்கான நிலையான நெட்வொர்க் காலக்கெடுவாகும் (எ.கா., OTP அனுப்ப ஆரம்ப கோரிக்கை மற்றும் அதை சரிபார்க்க இறுதி கோரிக்கை). இவை பொதுவாக குறுகியவை (எ.கா., 10-30 வினாடிகள்) மற்றும் நெட்வொர்க் இணைப்பு சிக்கல்களைக் கையாளுகின்றன.

கிளையன்ட் பக்க 'மீண்டும் அனுப்பு' கூல்டவுனை எஸ்எம்எஸ் விநியோகத்தின் உண்மைகள் மற்றும் சர்வர் பக்க செல்லுபடியாகும் காலத்துடன் ஒத்திசைத்து, பயனருக்கு ஒரு மென்மையான, தர்க்கரீதியான அனுபவத்தை உருவாக்குவதே முக்கிய சவாலாகும்.

முக்கிய சவால்: பாதுகாப்பு, பயனர் அனுபவம் மற்றும் உலகளாவிய உண்மைகளை சமநிலைப்படுத்துதல்

சரியான காலக்கெடுவை உள்ளமைப்பது என்பது ஒரு ஒற்றை மந்திர எண்ணைக் கண்டுபிடிப்பது அல்ல. இது மூன்று போட்டி முன்னுரிமைகளை பூர்த்தி செய்யும் ஒரு இனிமையான இடத்தைக் கண்டுபிடிப்பதாகும்.

1. பாதுகாப்பு கண்ணோட்டம்

முற்றிலும் பாதுகாப்பு-மையப்படுத்தப்பட்ட கண்ணோட்டத்தில், குறுகிய காலக்கெடு எப்போதும் சிறந்தது. சர்வரில் ஒரு குறுகிய OTP செல்லுபடியாகும் காலம், ஒரு தாக்குபவர் குறியீட்டை இடைமறிக்க அல்லது வேறுவிதமாக சமரசம் செய்வதற்கான வாய்ப்பைக் குறைக்கிறது. கிளையன்ட் பக்க 'மீண்டும் அனுப்பு' டைமர் குறியீட்டின் செல்லுபடியாகும் தன்மையை நேரடியாக பாதிக்கவில்லை என்றாலும், அது பாதுகாப்பு தாக்கங்களைக் கொண்டிருக்கக்கூடிய பயனர் நடத்தையை பாதிக்கிறது. உதாரணமாக, மிக நீண்ட 'மீண்டும் அனுப்பு' டைமர் ஒரு பயனரை பாதுகாப்பான உள்நுழைவு செயல்முறையை முற்றிலுமாக கைவிட விரக்தியடையச் செய்யலாம்.

• ஆபத்து குறைப்பு: குறுகிய சர்வர் பக்க செல்லுபடியாகும் காலம் (எ.கா., 3 நிமிடங்கள்) ஒரு குறியீடு சமரசம் செய்யப்பட்டு பின்னர் பயன்படுத்தப்படும் அபாயத்தைக் குறைக்கிறது.
• Brute-Force தடுப்பு: சர்வர் OTP உருவாக்கம் மற்றும் சரிபார்ப்பு முயற்சிகளில் rate-limiting-ஐ கையாள வேண்டும். இருப்பினும், ஒரு நன்கு வடிவமைக்கப்பட்ட frontend கூல்டவுன் முதல் பாதுகாப்பு அரணாக செயல்பட முடியும், இது ஒரு தீங்கிழைக்கும் ஸ்கிரிப்ட் அல்லது விரக்தியடைந்த பயனர் எஸ்எம்எஸ் கேட்வேயை நிரப்புவதைத் தடுக்கிறது.

2. பயனர் அனுபவம் (UX) கண்ணோட்டம்

பயனரைப் பொறுத்தவரை, OTP செயல்முறை ஒரு தடை—அவர்கள் தங்கள் இலக்கை அடையும் முன் ஒரு அவசியமான தாமதம். இந்த தடையை முடிந்தவரை தாழ்வாக மாற்றுவதே நமது வேலை.

• காத்திருப்பின் கவலை: ஒரு பயனர் "குறியீட்டை அனுப்பு" என்பதைக் கிளிக் செய்யும்போது, ஒரு மனக் கடிகாரம் தொடங்குகிறது. எஸ்எம்எஸ் அவர்களின் உணர்ந்த 'சாதாரண' காலக்கெடுவுக்குள் (இது பெரும்பாலும் சில வினாடிகள் தான்) வரவில்லை என்றால், அவர்கள் கவலைப்படத் தொடங்குகிறார்கள். நான் எனது எண்ணை சரியாக உள்ளிட்டேனா? சேவை முடங்கியுள்ளதா?
• முன்கூட்டியே மீண்டும் அனுப்புதல்: 'மீண்டும் அனுப்பு' பொத்தான் மிக விரைவில் கிடைத்தால் (எ.கா., 15 வினாடிகளுக்குப் பிறகு), பல பயனர்கள் அதை அனிச்சையாக கிளிக் செய்வார்கள். இது அவர்கள் பல OTP-களைப் பெற்று, எது மிகச் சமீபத்திய மற்றும் செல்லுபடியாகும் என்று தெரியாமல் குழப்பமான சூழ்நிலைக்கு வழிவகுக்கும்.
• கட்டாய காத்திருப்பின் விரக்தி: மாறாக, கூல்டவுன் மிக நீளமாக இருந்தால் (எ.கா., 2 நிமிடங்கள்), மற்றும் எஸ்எம்எஸ் உண்மையிலேயே வரத் தவறினால், பயனர் செயலிழந்த பொத்தானைப் பார்த்துக்கொண்டு, சக்தியற்றவராகவும் விரக்தியுடனும் உணர்கிறார்.

3. உலகளாவிய உண்மைகள் கண்ணோட்டம்

இது பல வளர்ச்சி அணிகள், பெரும்பாலும் நன்கு இணைக்கப்பட்ட நகர்ப்புற மையங்களில் இருப்பவர்கள், மறந்துவிடும் மாறி. எஸ்எம்எஸ் விநியோகம் உலகளவில் சீரான, உடனடி சேவை அல்ல.

• நெட்வொர்க் தாமதம்: விநியோக நேரம் வியத்தகு रूपத்தில் மாறுபடலாம். ஒரு எஸ்எம்எஸ் தென் கொரியாவில் 5 வினாடிகள், கிராமப்புற இந்தியாவில் 30 வினாடிகள், மற்றும் தென் அமெரிக்கா அல்லது ஆப்பிரிக்காவின் சில பகுதிகளில் ஒரு நிமிடத்திற்கு மேல் ஆகலாம், குறிப்பாக நெட்வொர்க் நெரிசல் உச்சத்தில் இருக்கும்போது. உங்கள் காலக்கெடு வேகமான நெட்வொர்க்கில் உள்ள பயனருக்கு மட்டுமல்ல, மெதுவான நெட்வொர்க்கில் உள்ள பயனருக்கும் இடமளிக்க வேண்டும்.
• கேரியர் நம்பகத்தன்மை மற்றும் "பிளாக் ஹோல்கள்": சில நேரங்களில், ஒரு எஸ்எம்எஸ் செய்தி வெறுமனே மறைந்துவிடும். அது கேட்வேயை விட்டு வெளியேறுகிறது ஆனால் கேரியர் வடிகட்டுதல், முழு இன்பாக்ஸ், அல்லது பிற மர்மமான நெட்வொர்க் சிக்கல்கள் காரணமாக பயனரின் சாதனத்தை ஒருபோதும் சென்றடையாது. பயனர் இந்த சூழ்நிலையிலிருந்து ஒரு நித்தியம் காத்திருக்காமல் மீள ஒரு வழி தேவை.
• பயனர் சூழல் மற்றும் கவனச்சிதறல்கள்: பயனர்கள் எப்போதும் தங்கள் தொலைபேசிகளில் ஒட்டிக்கொண்டிருப்பதில்லை. அவர்கள் வாகனம் ஓட்டலாம், சமைக்கலாம், அல்லது தங்கள் தொலைபேசியை மற்றொரு அறையில் வைத்திருக்கலாம். ஒரு காலக்கெடு பயனர் சூழலை மாற்றி, தங்கள் சாதனத்தைக் கண்டுபிடித்து, செய்தியைப் படிக்க போதுமான இடையகத்தை வழங்க வேண்டும்.

உங்கள் "மீண்டும் குறியீட்டை அனுப்பு" கூல்டவுனை உள்ளமைப்பதற்கான சிறந்த நடைமுறைகள்

போட்டியிடும் காரணிகளைக் கருத்தில் கொண்டு, ஒரு வலுவான மற்றும் பயனர் நட்பு frontend டைமரை அமைப்பதற்கான சில செயல்முறைப்படுத்தக்கூடிய சிறந்த நடைமுறைகளை நிறுவுவோம்.

60-வினாடி விதி: ஒரு விவேகமான தொடக்கப் புள்ளி

ஒரு உலகளாவிய பயன்பாட்டிற்கு, முதல் 'மீண்டும் அனுப்பு' கோரிக்கைக்காக 60-வினாடி கூல்டவுன் டைமருடன் தொடங்குவது பரவலாக ஏற்றுக்கொள்ளப்பட்ட மற்றும் பயனுள்ள அடிப்படையாகும். ஏன் 60 வினாடிகள்?

• குறைந்த நம்பகமான நெட்வொர்க்குகளில் கூட, உலகெங்கிலும் உள்ள பெரும்பாலான எஸ்எம்எஸ் விநியோக தாமதங்களை ஈடுகட்ட இது போதுமானது.
• காத்திருக்கும் பயனருக்கு இது ஒரு நித்தியம் போல் தோன்றாத அளவுக்கு குறுகியது.
• இது பயனரை முதல் செய்திக்காக காத்திருக்க வலுவாக ஊக்குவிக்கிறது, அவர்கள் பல, குழப்பமான OTP-களைத் தூண்டும் வாய்ப்பைக் குறைக்கிறது.

சிறந்த உள்கட்டமைப்பு உள்ள சந்தைகளுக்கு 30 வினாடிகள் கவர்ச்சிகரமானதாக இருக்கலாம், ஆனால் இது ஒரு உலகளாவிய பார்வையாளர்களுக்கு ஒதுக்குவதாக இருக்கலாம். 60 வினாடிகளுடன் தொடங்குவது நம்பகத்தன்மைக்கு முன்னுரிமை அளிக்கும் ஒரு உள்ளடக்கிய அணுகுமுறையாகும்.

முற்போக்கான காலக்கெடுவை (Exponential Backoff) செயல்படுத்தவும்

ஒருமுறை 'மீண்டும் அனுப்பு' என்பதைக் கிளிக் செய்யும் பயனர் பொறுமையற்றவராக இருக்கலாம். பலமுறை அதைக் கிளிக் செய்ய வேண்டிய பயனர் உண்மையான விநியோக சிக்கலைக் கொண்டிருக்கலாம். ஒரு முற்போக்கான காலக்கெடு உத்தி, அதாவது exponential backoff, இந்த வேறுபாட்டை மதிக்கிறது.

ஒவ்வொரு அடுத்தடுத்த 'மீண்டும் அனுப்பு' கோரிக்கைக்குப் பிறகும் கூல்டவுன் காலத்தை அதிகரிப்பதே இதன் யோசனை. இது இரண்டு நோக்கங்களுக்கு உதவுகிறது: இது பயனரை மற்ற விருப்பங்களை ஆராய மெதுவாகத் தூண்டுகிறது, மேலும் இது உங்கள் சேவையை (மற்றும் உங்கள் பணப்பையை) ஸ்பேம் செய்யப்படுவதிலிருந்து பாதுகாக்கிறது.

உதாரண முற்போக்கான காலக்கெடு உத்தி:

• முதல் மீண்டும் அனுப்புதல்: 60 வினாடிகளுக்குப் பிறகு கிடைக்கும்.
• இரண்டாவது மீண்டும் அனுப்புதல்: 90 வினாடிகளுக்குப் பிறகு கிடைக்கும்.
• மூன்றாவது மீண்டும் அனுப்புதல்: 120 வினாடிகளுக்குப் பிறகு கிடைக்கும்.
• மூன்றாவது மீண்டும் அனுப்பிய பிறகு: "இன்னும் சிக்கல் உள்ளதா? மற்றொரு சரிபார்ப்பு முறையை முயற்சிக்கவும் அல்லது ஆதரவைத் தொடர்பு கொள்ளவும்" போன்ற ஒரு செய்தியைக் காண்பிக்கவும்.

இந்த அணுகுமுறை பயனர் எதிர்பார்ப்புகளை நிர்வகிக்கிறது, வளங்களைச் சேமிக்கிறது (எஸ்எம்எஸ் செய்திகள் இலவசம் அல்ல), மற்றும் உண்மையிலேயே சிக்கியுள்ள பயனர்களுக்கு ஒரு மென்மையான வெளியேற்றப் பாதையை வழங்குகிறது.

தெளிவாகவும் முன்கூட்டியும் தொடர்பு கொள்ளவும்

டைமரைச் சுற்றியுள்ள பயனர் இடைமுகம் டைமரின் கால அளவைப் போலவே முக்கியமானது. உங்கள் பயனர்களை இருட்டில் விடாதீர்கள்.

• தெளிவாக இருங்கள்: ஆரம்ப கோரிக்கைக்குப் பிறகு, உடனடியாக செயலை உறுதிப்படுத்தவும். ஒரு பொதுவான "குறியீடு அனுப்பப்பட்டது" என்பதற்குப் பதிலாக, மேலும் விவரிக்கக்கூடிய உரையைப் பயன்படுத்தவும்: "நாங்கள் +XX-XXXXXX-XX12 என்ற எண்ணுக்கு 6 இலக்கக் குறியீட்டை அனுப்பியுள்ளோம். அது வருவதற்கு ஒரு நிமிடம் வரை ஆகலாம்." இது தொடக்கத்திலிருந்தே ஒரு யதார்த்தமான எதிர்பார்ப்பை அமைக்கிறது.
• தெரியும்படியான கவுண்ட்டவுனைக் காட்டுங்கள்: மிக முக்கியமான UI கூறு தெரியும் டைமர் ஆகும். முடக்கப்பட்ட 'மீண்டும் அனுப்பு' பொத்தானை ஒரு செய்தியுடன் மாற்றவும்: "0:59 இல் குறியீட்டை மீண்டும் அனுப்பவும்". இந்த காட்சி பின்னூட்டம் கணினி வேலை செய்கிறது என்று பயனருக்கு உறுதியளிக்கிறது மற்றும் அவர்களுக்கு ஒரு தெளிவான, உறுதியான காலக்கெடுவை அளிக்கிறது, இது கவலையை கணிசமாகக் குறைக்கிறது.
• சரியான நேரத்தில் மாற்று வழிகளை வழங்குங்கள்: பயனரை ஐந்து சரிபார்ப்பு விருப்பங்களுடன் ஆரம்பத்திலேயே மூழ்கடிக்காதீர்கள். முதல் அல்லது இரண்டாவது எஸ்எம்எஸ் மீண்டும் அனுப்பும் முயற்சிக்குப் பிறகு மட்டுமே மாற்று வழிகளை (எ.கா., "குரல் அழைப்பு மூலம் குறியீட்டைப் பெறுங்கள்," "மின்னஞ்சலுக்கு குறியீட்டை அனுப்புங்கள்") அறிமுகப்படுத்துங்கள். இது தேவைப்படுபவர்களுக்கு பின்னடைவு விருப்பங்களுடன் ஒரு சுத்தமான, கவனம் செலுத்திய ஆரம்ப அனுபவத்தை உருவாக்குகிறது.

தொழில்நுட்ப செயல்படுத்தல்: Frontend குறியீடு உதாரணங்கள்

இந்த செயல்பாட்டை எவ்வாறு உருவாக்குவது என்று பார்ப்போம். நாங்கள் ஒரு framework-agnostic vanilla JavaScript உதாரணத்துடன் தொடங்குவோம், அனுபவத்தை மேம்படுத்தக்கூடிய நவீன உலாவி API-களைப் பற்றி விவாதிப்போம், மற்றும் அணுகல்தன்மையைத் தொடுவோம்.

Vanilla JavaScript-இல் அடிப்படை கவுண்ட்டவுன் டைமர்

இந்த உதாரணம் ஒரு கவுண்ட்டவுன் டைமரின் நிலையை எவ்வாறு நிர்வகிப்பது மற்றும் அதற்கேற்ப UI-ஐப் புதுப்பிப்பது என்பதைக் காட்டுகிறது.

```html

உங்கள் சரிபார்ப்புக் குறியீட்டை உள்ளிடவும்

உங்கள் தொலைபேசிக்கு ஒரு குறியீட்டை அனுப்பியுள்ளோம். தயவுசெய்து அதை கீழே உள்ளிடவும்.

குறியீட்டை சரிபார்க்கவும் ``` ```javascript // DOM முழுமையாக ஏற்றப்படும் வரை காத்திருக்கவும் document.addEventListener('DOMContentLoaded', () => { const resendButton = document.getElementById('resendButton'); const timerSpan = document.getElementById('timer'); let countdown; let timerInterval; function startTimer(duration) { countdown = duration; resendButton.disabled = true; timerSpan.textContent = countdown; resendButton.innerHTML = `குறியீட்டை மீண்டும் அனுப்ப ${countdown}s`; timerInterval = setInterval(() => { countdown--; timerSpan.textContent = countdown; if (countdown <= 0) { clearInterval(timerInterval); resendButton.disabled = false; resendButton.textContent = 'மீண்டும் குறியீட்டை அனுப்பு'; } }, 1000); } resendButton.addEventListener('click', () => { // ஒரு உண்மையான பயன்பாட்டில், OTP-ஐ மீண்டும் அனுப்ப உங்கள் API-ஐ இங்கே அழைப்பீர்கள் console.log('OTP மீண்டும் அனுப்பப்படுகிறது...'); // டைமரை மீண்டும் தொடங்கவும் (இங்கே நீங்கள் ஒரு முற்போக்கான கால அளவைப் பயன்படுத்தலாம்) startTimer(60); }); // பக்கம் ஏற்றப்பட்டவுடன் டைமரைத் தொடங்கவும் startTimer(60); }); ```

இந்த எளிய ஸ்கிரிப்ட் முக்கிய செயல்பாட்டை வழங்குகிறது. முற்போக்கான காலக்கெடு தர்க்கத்தை செயல்படுத்த, மீண்டும் அனுப்பும் முயற்சிகளின் எண்ணிக்கையை ஒரு மாறியில் கண்காணிப்பதன் மூலம் இதை நீங்கள் விரிவாக்குவீர்கள்.

ஒரு கேம் சேஞ்சர்: WebOTP API

செய்திகளை கைமுறையாகச் சரிபார்த்து குறியீடுகளை நகலெடுத்து ஒட்டுவது ஒரு உராய்வு புள்ளி. நவீன உலாவிகள் ஒரு சக்திவாய்ந்த தீர்வை வழங்குகின்றன: WebOTP API. இந்த API உங்கள் வலை பயன்பாட்டிற்கு பயனரின் ஒப்புதலுடன் ஒரு எஸ்எம்எஸ் செய்தியிலிருந்து ஒரு OTP-ஐ நிரல்ரீதியாகப் பெறவும், படிவத்தை தானாக நிரப்பவும் அனுமதிக்கிறது. இது ஒரு நேட்டிவ் ஆப் போன்ற அனுபவத்தை உருவாக்குகிறது.

இது எப்படி வேலை செய்கிறது:

1. எஸ்எம்எஸ் செய்தி சிறப்பாக வடிவமைக்கப்பட்டிருக்க வேண்டும். அது உங்கள் வலை பயன்பாட்டின் மூலத்தை (origin) இறுதியில் சேர்க்க வேண்டும். உதாரணம்: உங்கள் சரிபார்ப்புக் குறியீடு 123456. @www.your-app.com #123456
2. frontend-இல், நீங்கள் JavaScript-ஐப் பயன்படுத்தி OTP-க்காகக் காத்திருக்கிறீர்கள்.

அதன் சொந்த காலக்கெடு அம்சத்தையும் சேர்த்து, அதை எவ்வாறு செயல்படுத்தலாம் என்பது இங்கே:

```javascript async function listenForOTP() { if ('OTPCredential' in window) { console.log('WebOTP API ஆதரிக்கப்படுகிறது.'); try { const abortController = new AbortController(); // API-க்கே ஒரு காலக்கெடுவை அமைக்கவும். // 2 நிமிடங்களில் சரியாக வடிவமைக்கப்பட்ட எஸ்எம்எஸ் வரவில்லை என்றால், அது ரத்து செய்யப்படும். setTimeout(() => { abortController.abort(); }, 2 * 60 * 1000); const otpCredential = await navigator.credentials.get({ otp: { transport: ['sms'] }, signal: abortController.signal }); if (otpCredential && otpCredential.code) { const otpCode = otpCredential.code; document.getElementById('otpInput').value = otpCode; // விருப்பமாக, நீங்கள் இங்கே படிவத்தை தானாக சமர்ப்பிக்கலாம். console.log('OTP தானாகப் பெறப்பட்டது:', otpCode); document.getElementById('verifyButton').click(); } else { console.log('OTP சான்று பெறப்பட்டது ஆனால் காலியாக இருந்தது.'); } } catch (err) { console.error('WebOTP API பிழை:', err); } } } // OTP பக்கம் ஏற்றப்படும்போது இந்த செயல்பாட்டை அழைக்கவும் listenForOTP(); ```

முக்கிய குறிப்பு: WebOTP API ஒரு அருமையான மேம்பாடு, கைமுறை ஓட்டத்திற்கு மாற்றானது அல்ல. API-ஐ ஆதரிக்காத உலாவிகளுக்காக அல்லது தானியங்கி மீட்டெடுப்பு தோல்வியுற்றால், நீங்கள் எப்போதும் கைமுறை உள்ளீட்டு புலம் மற்றும் 'மீண்டும் அனுப்பு' டைமரை ஒரு பின்னடைவாக வழங்க வேண்டும்.

ஒரு உலகளாவிய பார்வையாளர்களுக்கான மேம்பட்ட பரிசீலனைகள்

ஒரு உலகத்தரம் வாய்ந்த OTP அமைப்பை உண்மையிலேயே உருவாக்க, நாம் ஒரு எளிய டைமருக்கு அப்பாற்பட்ட சில மேம்பட்ட தலைப்புகளைக் கருத்தில் கொள்ள வேண்டும்.

டைனமிக் காலக்கெடு: ஒரு கவர்ச்சியான ஆனால் தந்திரமான யோசனை

வேகமான நெட்வொர்க்குகள் உள்ள நாடுகளில் உள்ள பயனர்களுக்கு குறுகிய காலக்கெடுவையும், மற்றவர்களுக்கு நீண்ட காலக்கெடுவையும் அமைக்க IP புவிஇருப்பிடத்தைப் பயன்படுத்த ஒருவர் ஆசைப்படலாம். கோட்பாட்டில் புத்திசாலித்தனமாக இருந்தாலும், இந்த அணுகுமுறை பெரும்பாலும் சிக்கல்கள் நிறைந்தது:

• தவறான புவிஇருப்பிடம்: IP-அடிப்படையிலான இடம் நம்பமுடியாததாக இருக்கலாம். VPN-கள், ப்ராக்ஸிகள் மற்றும் கார்ப்பரேட் நெட்வொர்க்குகள் ஒரு பயனரின் உண்மையான இருப்பிடத்தை முற்றிலும் தவறாகக் காட்டலாம்.
• நுண்-பிராந்திய வேறுபாடுகள்: நெட்வொர்க் தரம் இரண்டு வெவ்வேறு நாடுகளுக்கு இடையில் இருப்பதை விட ஒரு பெரிய நாட்டிற்குள் அதிகமாக மாறுபடலாம். அமெரிக்காவின் ஒரு கிராமப்புறப் பகுதியில் உள்ள ஒரு பயனர், மும்பையின் நகர்ப்புறத்தில் உள்ள ஒருவரை விட மோசமான இணைப்பைக் கொண்டிருக்கலாம்.
• பராமரிப்பு சுமை: இது ஒரு சிக்கலான, உடையக்கூடிய அமைப்பை உருவாக்குகிறது, இது தொடர்ந்து புதுப்பித்தல் மற்றும் பராமரிப்பு தேவைப்படுகிறது.

பரிந்துரை: பெரும்பாலான பயன்பாடுகளுக்கு, அனைவருக்கும் வேலை செய்யும் ஒரு உலகளாவிய, தாராளமான காலக்கெடுவை (நமது 60-வினாடி அடிப்படை போன்றவை) பின்பற்றுவது மிகவும் வலுவானது மற்றும் எளிமையானது.

அணுகல்தன்மை (a11y) பேச்சுவார்த்தைக்குட்பட்டதல்ல

ஒரு ஸ்கிரீன் ரீடரை நம்பியிருக்கும் பயனர் உங்கள் OTP படிவத்தின் நிலையைப் புரிந்து கொள்ள வேண்டும். உங்கள் செயல்படுத்தல் அணுகக்கூடியதாக இருப்பதை உறுதிசெய்யவும்:

• டைனமிக் மாற்றங்களை அறிவிக்கவும்: டைமர் தொடங்கும்போதும், புதுப்பிக்கும்போதும், முடியும்போதும், இந்த மாற்றம் உதவி தொழில்நுட்பங்களுக்கு அறிவிக்கப்பட வேண்டும். ஒரு `aria-live` பகுதியைப் பயன்படுத்துவதன் மூலம் இதை நீங்கள் அடையலாம். உங்கள் JavaScript உரையை "45 வினாடிகளில் குறியீட்டை மீண்டும் அனுப்பவும்" என்று புதுப்பிக்கும்போது, ஒரு ஸ்கிரீன் ரீடர் அதை அறிவிக்கும்.
• தெளிவான பொத்தான் நிலைகள்: 'மீண்டும் அனுப்பு' பொத்தான் தெளிவான ஃபோகஸ் நிலைகளைக் கொண்டிருக்க வேண்டும் மற்றும் அதன் நிலையை நிரல்ரீதியாகத் தெரிவிக்க `aria-disabled` போன்ற ARIA பண்புகளைப் பயன்படுத்த வேண்டும்.
• அணுகக்கூடிய உள்ளீடுகள்: உங்கள் OTP உள்ளீட்டு புலங்கள் சரியாக லேபிளிடப்பட்டுள்ளதா என்பதை உறுதிப்படுத்தவும். நீங்கள் ஒரு ஒற்றை உள்ளீட்டைப் பயன்படுத்தினால், `autocomplete="one-time-code"` கடவுச்சொல் மேலாளர்கள் மற்றும் உலாவிகள் குறியீட்டை தானாக நிரப்ப உதவும்.

சர்வர் பக்க ஒத்திசைவு குறித்த ஒரு முக்கிய குறிப்பு

frontend டைமர் ஒரு UX மேம்பாடு, ஒரு பாதுகாப்பு அம்சம் அல்ல என்பதை நினைவில் கொள்வது அவசியம். OTP செல்லுபடியாகும் உண்மைக்கான ஆதாரம் எப்போதும் உங்கள் backend ஆகும்.

உங்கள் frontend மற்றும் backend தர்க்கம் இணக்கமாக இருப்பதை உறுதிசெய்யவும். உதாரணமாக, உங்கள் backend OTP 3 நிமிடங்களுக்கு மட்டுமே செல்லுபடியாகும் என்றால், 4 நிமிடங்களுக்குப் பிறகு தொடங்கும் மூன்றாவது frontend 'மீண்டும் அனுப்பு' கூல்டவுனைக் கொண்டிருப்பது ஒரு மோசமான பயனர் அனுபவமாக இருக்கும். பயனர் இறுதியாக ஒரு புதிய குறியீட்டைக் கோர முடியும், ஆனால் அவர்களின் முந்தைய குறியீடுகள் நீண்ட காலத்திற்கு முன்பே காலாவதியாகிவிட்டிருக்கும். ஒரு நல்ல விதிமுறை என்னவென்றால், உங்கள் முழு முற்போக்கான கூல்டவுன் வரிசையும் சர்வரின் OTP செல்லுபடியாகும் காலத்திற்குள் வசதியாக முடிவடைவதை உறுதி செய்வதாகும்.

அனைத்தையும் ஒன்றாக இணைத்தல்: ஒரு பரிந்துரைக்கப்பட்ட உத்தி சரிபார்ப்புப் பட்டியல்

எந்தவொரு திட்டத்திற்கும் ஒரு நடைமுறை, செயல்முறைப்படுத்தக்கூடிய உத்தியாக நமது கண்டுபிடிப்புகளை ஒருங்கிணைப்போம்.

1. ஒரு விவேகமான அடிப்படையை அமைக்கவும்: முதல் மீண்டும் அனுப்பும் கோரிக்கைக்கு 60-வினாடி கூல்டவுனுடன் தொடங்கவும். இது உலகளவில் அணுகக்கூடிய ஒரு அமைப்பிற்கான உங்கள் அடித்தளமாகும்.
2. முற்போக்கான பேக்ஆஃப்பை செயல்படுத்தவும்: பயனர் நடத்தையை நிர்வகிக்கவும் செலவுகளைக் கட்டுப்படுத்தவும் அடுத்தடுத்த மீண்டும் அனுப்புதல்களுக்கான கூல்டவுனை அதிகரிக்கவும் (எ.கா., 60வி -> 90வி -> 120வி).
3. ஒரு தகவல்தொடர்பு UI-ஐ உருவாக்கவும்:
   • குறியீடு அனுப்பப்பட்டதை உடனடியாக உறுதிப்படுத்தவும்.
   • ஒரு தெளிவான, தெரியும் கவுண்ட்டவுன் டைமரைக் காண்பிக்கவும்.
   • சரியான லேபிள்கள் மற்றும் ARIA பண்புகளுடன் பொத்தான்கள் மற்றும் இணைப்புகளை அணுகக்கூடியதாக மாற்றவும்.
4. நவீன API-களைத் தழுவுங்கள்: ஆதரிக்கப்படும் உலாவிகளில் உள்ள பயனர்களுக்கு ஒரு தடையற்ற, தானாக நிரப்பும் அனுபவத்தை வழங்க WebOTP API-ஐ ஒரு முற்போக்கான மேம்பாடாகப் பயன்படுத்தவும்.
5. எப்போதும் ஒரு பின்னடைவை வழங்கவும்: உலாவி ஆதரவைப் பொருட்படுத்தாமல், அனைத்து பயனர்களுக்கும் உங்கள் கைமுறை உள்ளீட்டு புலம் மற்றும் மீண்டும் அனுப்பும் டைமர் சரியாக வேலை செய்வதை உறுதிசெய்யவும்.
6. மாற்றுப் பாதைகளை வழங்கவும்: ஒன்று அல்லது இரண்டு தோல்வியுற்ற எஸ்எம்எஸ் முயற்சிகளுக்குப் பிறகு, மின்னஞ்சல், குரல் அழைப்பு, அல்லது ஒரு அங்கீகரிப்பு செயலி போன்ற பிற சரிபார்ப்பு முறைகளை நளினமாக அறிமுகப்படுத்துங்கள்.
7. Backend-உடன் சீரமைக்கவும்: உங்கள் frontend காலக்கெடு தர்க்கம் சர்வர் பக்க OTP செல்லுபடியாகும் காலத்திற்குள் (எ.கா., அதிகபட்சம் 3-4 நிமிடங்கள் எடுக்கும் ஒரு ஓட்டத்திற்கு 5 நிமிட சர்வர் செல்லுபடியாகும் காலம்) நன்கு உள்ளதா என்பதை உறுதிப்படுத்த உங்கள் backend குழுவுடன் ஒருங்கிணைக்கவும்.

முடிவுரை: சாதாரணமானதை மகத்தானதாக உயர்த்துதல்

ஒரு எஸ்எம்எஸ் ஓடிபி காலக்கெடுவின் கட்டமைப்பு என்பது எளிதில் கவனிக்கப்படாத ஒரு விவரம், இது பெரும்பாலும் கடைசி நிமிட முடிவு அல்லது கடினமாக குறியிடப்பட்ட இயல்புநிலை மதிப்புக்கு ஒதுக்கப்படும். ஆயினும்கூட, நாம் பார்த்தது போல், இந்த ஒற்றை அமைப்பு பாதுகாப்பு, பயன்பாட்டினை மற்றும் உலகளாவிய செயல்திறனின் ஒரு முக்கியமான சந்திப்பாகும். இது ஒரு பயனரை தடையற்ற உள்நுழைவுடன் மகிழ்விக்கும் சக்தியைக் கொண்டுள்ளது அல்லது அவர்களை உங்கள் சேவையை முற்றிலுமாக கைவிடும் அளவிற்கு விரக்தியடையச் செய்யும்.

ஒரு அளவு அனைவருக்கும் பொருந்தும் அணுகுமுறைக்கு அப்பால் சென்று, முற்போக்கான கூல்டவுன்கள், தெளிவான தகவல்தொடர்பு மற்றும் நவீன API-களைத் தழுவும் ஒரு சிந்தனைமிக்க, பச்சாதாபமான உத்தியை ஏற்றுக்கொள்வதன் மூலம், இந்த சாதாரண படியை பயனர் பயணத்தில் ஒரு மகத்தான தருணமாக மாற்ற முடியும். ஒரு போட்டி உலகளாவிய சந்தையில், நம்பிக்கையை உருவாக்குவதும் உராய்வைக் குறைப்பதும் மிக முக்கியம். நன்கு கட்டமைக்கப்பட்ட ஒரு OTP ஓட்டம், நீங்கள் அவர்களின் நேரத்தை மதிக்கிறீர்கள், அவர்களின் சூழலை மதிக்கிறீர்கள், மற்றும் ஒரு நொடிக்கு ஒரு நொடி உண்மையான உலகத்தரம் வாய்ந்த அனுபவத்தை வழங்க உறுதிபூண்டுள்ளீர்கள் என்று உங்கள் பயனர்களுக்கு ஒரு தெளிவான சமிக்ஞையாகும்.